「客戶一直改」和「我們一直沒問」在現場長得一模一樣；分不出來的團隊，會把自己的帳記到客戶頭上。

三個「不是這樣」

昨天的結尾，團隊把那個終於誠實的「處理中」畫面拿給客服主管看，她說了第一句「不是這樣」：超過七天要簽核。

今天把這場 Demo 講完。她總共說了三次。

第一次就是那句：「超過七天的訂單，客服不能直接退，要財務簽核。七天內的全額退款，我們才能自己核。」

第二次發生在前端工程師換了一筆測試訂單繼續示範的時候：「等等，這筆已經出貨了。已出貨的不能這樣直接退，流程不一樣。」

第三次是散會前，她補了一句：「對了，刷卡退款發票要開折讓，這塊你們有跟財務對過嗎？」

會議室的空氣，跟整合日那天一樣冷。散會後，工程團隊的內部頻道炸了：

「需求一直改！」

「當初只說『加一個線上退款功能』，現在多出簽核流程、出貨判斷、發票折讓——這是三個新功能了吧。」

這些話傳到客服主管耳裡，她比誰都冤：

「這些規則一直都在啊。我們人工退款每天都在做這三件事。是你們沒問。」

兩邊都覺得自己有理，兩邊也都覺得被對方坑了。所以今天只處理一個問題：她的三個「不是這樣」，到底是不是需求變更？

當時團隊怎麼理解

工程團隊的推論是這樣的：我們是敏捷團隊，需求會變很正常；客戶看了 Demo 才提出新要求，這就是回饋，回饋帶來變更；Day 05 也說過沒有免費的 Change，變更就該重新估算、重新排程；所以這是三張新的 Change 單，帳記在客戶那邊。

每一句單獨看都對，甚至還正確引用了本系列前面的內容。合在一起只有一個問題：整條推論建立在「這三條規則是新的」這個前提上。

而這個前提是錯的。

改了的需求，和終於被看見的需求

先把兩個詞放上桌：

Requirement Change（需求變更）
→ 一個已經存在、已經被看見的需求，如今要變成另一個樣子
→ 世界變了：規定改了、策略轉了、先前的決定被推翻

Requirement Discovery（需求發現）
→ 一條從專案第一天就存在的規則，如今才第一次被看見
→ 世界沒變，是我們對世界的理解變了

拿這把尺量那三個「不是這樣」。

七天簽核？那是客服與財務之間行之有年的權限規則，人工退款每一筆都在跑。已出貨不能直接退？那是客服收到退款申請後查單的第一個動作。發票折讓？財務每個月都在開。

三條規則，沒有一條是在 Demo 那天誕生的。它們一直都在，只是一直沒有被問到。三比零，全是 Discovery，沒有一件是 Change。

順便給一個對照組，讓尺更清楚：假如下個月財務宣布，簽核門檻從七天改成十四天——一條已經被看見的規則，變成另一個樣子——那才叫 Change。

你不能改一個不存在的東西

還有一個更根本的檢查法。Day 02 說過，瀑布的 Change 是對著 Baseline 走的：先有承諾，才有「改承諾」。換句話說——

要說一個需求「被改了」，它得先存在。

這個專案裡，被寫下來的需求是什麼？一張 Ticket，一句「幫我加一個線上退款功能」。三條規則沒有任何一條跟這句話矛盾——帶簽核的線上退款，仍然是線上退款。嚴格說，這個案子到今天為止，連一個 Change 都沒有發生過：沒有任何承諾被改動。

那被推翻的是什麼？是 Day 15 那天，每個人用自己的想像補完的那個版本。客服主管否定的從來不是承諾，是工程團隊的腦補。

想像被否定，不叫需求變更，叫對答案。

而 Day 15 在代價欄勾下 Risk 時寫的「帳單稍後寄達」——就是今天這張。沒被問出來的規則不會消失，它只是挑了一個最貴的時間點出現：做完之後。

順帶把兩套方法的原廠設計放回來。瀑布的做法，是把 Discovery 盡量壓到動工之前發生：需求分析的任務本來就是把「本來就在的規則」挖出來寫進 Baseline，之後才輪到 Change 管理登場。敏捷的做法不是取消這件事，而是承認一次問不完，所以縮短回饋週期，讓每一輪都有機會再問——Day 03 說過，敏捷最值錢的產出之一，是提早知道哪些東西做錯了。Discovery 越早發生越便宜；最貴的版本，就是這個團隊選的這種。

兩套方法都有安放它的位置。這個團隊的問題是兩邊都沒有：既沒有動工前的釐清，也沒有每一輪的對話，只有一句話 Ticket 和一路綠燈的看板。

為什麼這個區分重要：因為誤判是雙輸

有人會說：反正都要重工，叫 Change 還是 Discovery 有差嗎？

差很多。誤把 Discovery 當 Change，會同時輸三次。

第一，團隊覺得委屈。「客戶一直改」的敘事讓每一次重工都像被背刺，士氣的帳算在錯的人頭上。

第二，客戶覺得被刁難。客服主管講一條她用了好幾年的規則，卻被當成「臨時加需求」，還要被暗示該為重工負責。下次她會更少開口——而你最需要的，恰恰是她開口。

第三，也是最嚴重的：組織學到錯的教訓。檢討的結論會變成「客戶的需求管理有問題」，而不是「我們的需求釐清缺席了」。於是下一個專案，同一批人，原樣重演。

反過來，把真正的 Change 誤判成 Discovery 也會出事：客戶真的改了主意，卻不必付任何代價，Scope 就這樣靜靜長大。這把尺，兩個方向都要用。

還有一件事值得替客服主管說：她不是在推卸。這些規則對她來說像重力一樣自然，自然到想不到需要講。隱性知識不是只住在大神腦裡，也住在客戶腦裡——差別在於，客戶腦裡的那一份，從來只能靠問的。

如果大神在，這一天會怎麼過

老問題。第二部看過答案：Day 08 那位資深工程師，收到一句話需求會順手把十件事問完。這個案子如果他沒被借調走，大概開工第一週就會問出「這個金額誰核准？」「已出貨的怎麼辦？」——他被財務月底追過帳，他知道凡是動到錢的功能，背後一定站著一套財務規則。

然後 Demo 那天不會有任何「不是這樣」，專案順利上線，組織再次得到那個熟悉的結論：「你看，需求不用問清楚也沒事。」

這次他不在。「沒問」第一次用原價結帳。

重點從來不是他不在很可惜，而是：把規則問出來，是一項工程責任，不該取決於誰剛好在場。

這次到底誰在吸收代價？

Scope       □   沒有人重新談範圍，三條規則被當成插單硬吞
Time        ■   簽核流、出貨判斷、折讓——每一條都是回頭重工
Cost        □
Quality     □
Risk        □
人          ■   ← 重工的是工程團隊，黑鍋是客服主管的

注意「人」這格這次吸收的不只是加班：它還吸收了一段本來不必壞掉的信任。工程團隊與需求窗口互相扣帽子，是這種誤判最典型的副作用，而信任的維修費，比重工貴。

今日 Artifact｜變更／發現判別卡

下次有人喊「客戶又改需求了」，先別開 Change 單，把三題答完：

□ 這件事之前被承諾過嗎？
  （找得到寫下來的版本，才有資格談「改」；找不到，先別喊。）

□ 這條規則是新生的，還是本來就在？
  （問一句「這規則什麼時候開始的」——答案是「一直都這樣」，就是 Discovery。）

□ 如果當初問了 Day 15 的開工前五問，這件事會不會被問到？
  （會——帳記在我們的釐清缺席上；不會——它才有資格叫 Change。）

第三題順便自首：Day 15 那五問裡，本來就有一題叫「碰到誰的規則」。今天這三條，全部會在那一題現形。

判定完之後，兩條路都有既有的工具接手：Change 走 Day 05 的報價、記進 Day 12 的紀錄；Discovery 則把帳單收下，然後回頭補問當初沒問完的問題。兩條路都要付錢，差別在付錢的理由——以及下一次，還要不要再付一模一樣的錢。

今日一句

客戶沒有一直改需求；是需求一直在那裡，我們今天才第一次見到它。

把 Discovery 叫成 Change，只是這個案子搞錯的其中一件事。翻車翻到這裡，該把整台車翻過來檢查了。

明天來盤點：我們到底搞錯敏捷的哪幾件事？